Recent computer-based systems have been directed to providing support for rapid creation of simple web pages by users of minimal skill. Such systems are sometimes known as “Wikis” (from the Hawaiian expression “wiki wiki” meaning “fast”). Many such systems however provide users only with a text-based user interface, which limits their adoption by less skilled users. Some wikis therefore provide a so-called What You See Is What you Get (WYSIWYG) interface in an attempt to make such systems accessible to a wider user base.
Wikis may be used to create personal wikis: local “webs” for personal use, for example on a user's own personal computer, and in which many of the links may be made to local resources (e.g. files) rather than to remote resources using for example the Hypertext Transfer Protocol (HTTP). The ability to create such local web structures quickly and easily allows users to organise their own files in novel ways, by constructing local web pages which comprise hyperlinks to local files, and to determine their own page access and control policies.
However a problem with such systems is that, whilst such local web pages may be sent to other users, the local hyperlinks embedded within those pages are not effective on remote host computers, or indeed when selected by other users on the same computer, since they identify the resource locally relative to the creating user's local work space.
Peer-to-peer (P2P) computing is a model of distributed computing which does not distinguish between client and server computers (or software entities on computers), so that every computer (referred to as a peer) may act either as a client or as a server or as both. Related peers may be grouped together to form peer groups. The peer-to-peer paradigm is therefore quite distinct from the conventional client-server model of web-based applications in which servers provide services to clients but not vice versa. P2P computing is also characterised by the way in which computers are identified, and by the decentralised way in which computer identifiers are used to determine the mechanism by which one computer communicates with one or more other computers. This gives P2P computing an ability to traverse firewalls and accommodate Networks Address Translation (NAT) and the use of Dynamic Host Configuration Protocol (DHCP). Other known P2P frameworks (for example JXTA) use Relay and Rendezvous peers to achieve this.
P2P computing is often associated with file-sharing applications (such as Gnutella, Napster, WinMX® and Fileutopia) and Instant Messaging (IM).
Use of Asynchronous Pluggable Protocols within systems such as Microsoft Windows® gives users the ability to integrate new functionality within existing systems by substituting new protocols for existing ones. Such substitutions can be effected in such a way that almost any Windows application can subsequently make use of the new functionality. In particular, Windows provides an Asynchronous Pluggable Protocol (APP) to support interpretation of the Hypertext Transfer Protocol (HTTP) Uniform Resource Locator (URL) scheme used to reference remote resources on the web. Changes made to the HTTP URL scheme may therefore be implemented by substituting an amended HTTP APP. Remote resources referenced by hyperlinks are subsequently automatically accessed using the amended protocol from any application having links to a web page.
An example of how known web-based access systems operate is illustrated in FIG. 1. Server 10 comprises a file store 103 which contains web-accessible files 1030 and non-web-accessible files 1031. Local clients 104 (typically supporting local users) access files 1040 (for example web pages, spreadsheets, or text files) comprising one or more hyperlinks. These may take the known forms of HTTP URLs (“http:// . . . ”) 1041 or File URLs (file:// . . . ) 1042.
Such URLs are interpreted locally with reference to the local file management 103 or HTTP-client software. File-URLs result in direct access of locally stored file, including both web-accessible files 1030 and non-web-accessible files. HTTP-URLs result in access of the indicated file via a local HTTP client: the HTTP client determines whether the file is local or remote and accesses the web-accessible local file 1030 or a remote server accordingly.
A remote client 11 may also resolve URLs 1141 in locally accessible documents 114 but in that case the only URLs which resolve to a file on Server 10 are those which are HTTP-URLs. Typically such URLs may also refer to files on other servers 12.
A problem with this approach is that if a user on server 10 wishes to make a file available over the web to another (possibly remote) user, the file must first be copied or moved into the local web-accessible file area 1030 since there is no mechanism by which a remote user 11 can access the non-web-accessible files 1031 over the web.
A further problem is that if a first user is located within a first naming domain and wishes to make a file accessible to a second user in a second, different naming domain, then this is not easily achieved since resolution of the file address known to the first user in the second user's domain may not be successful. It is therefore desirable, at least in some cases, to provide means by which users my readily share files in such circumstances.